Description

Introduces a debug-assistant sub-agent that diagnoses failed pipeline runs by inspecting execution details, container state, and truncated logs. The agent is read-only and cannot mutate the pipeline spec or submit runs.

The dispatcher is refactored from a handoff-based architecture to an Agent.asTool(...) architecture, where each specialist (ask_general_help, ask_pipeline_repair, ask_debug_assistant) is exposed as a tool. This allows the dispatcher's own LLM loop to chain multiple specialist calls in a single turn — for example, calling ask_debug_assistant to identify a root cause and then ask_pipeline_repair to apply the fix, without requiring a separate user message.

pipeline-repair gains access to submit_pipeline_run so it can resubmit a run after a successful fix when the user explicitly requests it. The repair prompt is updated with a directive-based entry path: when the dispatcher passes a concrete CSOM mutation directive (e.g. derived from a debug-assistant diagnosis), pipeline-repair skips the validation-driven discovery flow and applies the targeted mutation directly.

The AgentSession now carries recentRuns, a list of the five most recent pipeline runs for the open pipeline. These are appended to the debug-assistant's system prompt at agent creation time so the model can resolve "my last run" or "the latest run" without an extra tool call.

New runTools and debugTools factories expose submit_pipeline_run, get_run_status, debug_pipeline_run, get_execution_details, get_execution_state, get_container_state, and get_container_log as agent tools. The toolBridge implements the corresponding ToolBridgeApi methods, including a composite debugPipelineRun that fetches the run, root execution state, and a truncated snapshot of every failed child execution in a single call. Payload truncation (log text capped at 8 KB, debug_info capped at 20 keys) is applied both in the bridge and in the debugTools layer to prevent large pod logs from consuming the model's context window.

The AiChatContent component fetches recent runs for the open pipeline via React Query and passes them through to the worker on each ask call. The fetchContainerLog helper is extracted into executionService and reused by both the existing logs UI component and the new bridge methods.

Observability status labels are added for the three new ask_* tool names so the status line updates correctly while a specialist is working inside a nested asTool run.

Related Issue and Pull requests

Type of Change

• Bug fix
• New feature
• Improvement
• Cleanup/Refactor
• Breaking change
• Documentation update

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

AI Assistant - Debug agent.mov (uploaded via Graphite)

Test Instructions

1. Open a pipeline that has at least one failed run.
2. Ask the assistant "Why did my last run fail?" — the debug-assistant should identify the failed task, cite the exit code and log excerpt, and emit a Fix to apply: directive if the cause is a single concrete input value error.
3. Ask "Investigate the recent failure and fix the pipeline" — the dispatcher should chain ask_debug_assistant followed by ask_pipeline_repair and return a combined diagnosis + change summary.
4. Ask "Investigate, fix, and rerun" — same as above but pipeline-repair should also submit a run and return the new run id.
5. Ask "Why did run <id> fail?" with an explicit run id to verify the agent resolves it directly without consulting the recent runs list.
6. Verify the status line updates during each specialist call (e.g. "Analyzing run failure..." while debug-assistant is working).
7. Confirm that asking a general Tangle question still routes correctly to ask_general_help.

Additional Comments

The Agent.asTool(...) migration means the agent_handoff event no longer fires from the dispatcher. The SUB_AGENT_LABELS map in observability.ts is retained for any sub-agent that uses internal handoffs, but the dispatcher's specialists are now covered by the ask_* entries under TOOL_STATUS_LABELS.